The bulk of these changes will merely expose certain issues in a more findable way. Here, you can see more easily that there should be a separate feature minted. It happens that this is already in progress with #2947.

Here's the first new application for these sets: linting our existing overrides. In autofocus, we've overridden the status to align with caniuse. By assigning the keys to the modifiers_name_tbc set, I'm declaring that all of the keys must meet the level given by the status override.

(We could have an implicit rule that a status override implies that a regular compat_features array is the modifiers_name_tbc set, but this seems too magical to me.)

Here's another exposure: key-sharing opportunities. Here we have a key that should probably exist on two features: backdrop and dialog. But the influence each of the key ought to have on the status differ, depending on the feature.

Here's an application: alignment with caniuse. Two keys are excluded from the birthday setting here, but we can now enforce that the remaining keys should be supported in the same set of browsers as the birthday set of keys.

That said, in this case (given the negative standards positions), we could probably eliminate the compute_from, if we coordinated with caniuse.

Here's another exposure: iffy upstream data. css.properties.border-radius.percentage is probably incorrect. But there's also an application here: we can accept the status level of this key and validate it against the headline status, without taking action on the upstream data immediately.

Later, we can ratchet this key into higher expectations, if and when we fix the upstream data.

This demonstrates a good application for incidentals_name_tbc: associating a key with the most-relevant feature, even though that key cannot contribute to the headline status.

In this case, api.Worker.Worker.mime_checks isn't a "feature" that a developer can use, but it is relevant restriction that developers will probably want to respect going forward.

See link-selectors for a closely-related situation.

Here's another application: ignoring data we can't really trust.

It turns out that I'm the original author of the majority of the hyphens.language_* data… almost ten years ago, when I migrated it from the MDN wiki. 😭 I do not really trust that this data is up-to-date (I'm not even sure it was terribly accurate at the time).

There's a subset here I do trust (this core_name_tbc set), but the rest… well, the one thing I can say here definitively is that these keys are related to the hyphens feature. So we might as well make that relationship explicit (and eventually burndown the incidentals list).

Here's another application: ignoring very minor issues.

There's a very poor case for breaking up link-rel-preload over as="track" support. The way I see it, the lack of support for as="track" is one browser's minor bug. Instead of making the platform seem much more complicated than it is by breaking this feature into 3 to 6 features, let's overlook this one key.

So, this falls into a domain I have some expertise on, and forgive me if the question seems naïve: Is it really incidental if the as="track" value has a small bug in one browser? If the intent is to fix the bug and bring it in line, should it remain under incidentals_name_tbc, or will it be eventually moved into core_name_tbc? Sorry if this question is a bit of a waste of time, but it does help my understanding!

Or rather, it could be moved into modifiers_name_tbc. The intent of the question is to see if these things eventually move into other categories when bugs surface or are fixed.

@malchata good question! In this case, I was under the impression that <link rel="preload" …> works for the overwhelmingly common uses (styles and scripts, though if I'm wrong about this I'm open to correction). With that assumption, I figured that means there's some preload feature that is Baseline.

That leaves us with as="track". Either we temporarily ignore it (as I've done) or mint a separate feature. If we ignore it as I've done, then — when as="track" is fixed — we'd promote the as-track key to the modifiers set (where it would be required to always have the same status as the core keys, but not necessarily the same exact ship date or versions).

Does that help explain the idea better?

This was more about an edge case—I do think that as="track" is not going to be nearly as common as say, as="script" or as="style". But it's a good example for what you're trying to communicate.

This does help explain the idea better, and thank you for taking the time to explain it! It gives me a bit of pause about how we think about features like this. Is rel="preload" in general one feature? Is it a feature that has several subfeatures (various as attribute values)? Or is each resource type its own feature? I don't pretend to be an expert, therefore are rhetorical questions, not questions you're obligated to answer!

Is rel="preload" in general one feature?

If this were a new feature today, I'd take one of two possible approaches:

• Mint a preload feature for every as="…" value
• Mint one preload feature that would not be Baseline until as="track" ships (with the option to break it up later, if it became clear that implementation would not happen across the board or at the same time)

In this case, preload predates web-features and Baseline. When we've minted existing features, we have tried to be consistent with established understandings of support (e.g., caniuse has a feature entry that overlooks as="track"). So we've followed caniuse's lead here, on the assumption that if the data has never been faulted on caniuse that developers don't actually care if as="track" works.

If developer understanding were to change (e.g., web-features or caniuse got complaints from developers or an Interop proposal on this subject succeeded), we might change the status here (i.e., by moving the as-track key to core_name_tbc) or break the feature up, probably in coordination with caniuse and MDN.

Here's another application: capturing behavior evolution for reverse features, where the platform took abilities away from developers.

In this case, these keys do not represent a "feature" at all. Instead, they represent a privacy limitation and a way this feature interacts with another feature (the <link> element), or rather how they do not interact with each other. It would be silly to mint a feature for "Not selecting <link> link elements with :link", so modifiers_name_tbc lets us sidestep doing something silly.

The last one here helps queue up the future by exposing candidates for (retroactive) feature merging. Once we implement feature merging, the reversed attribute might make sense as a separate feature that has merged into list-elements. Here's it's exposed as a possibility that we might author later.

Is there prior art for telegraphing things that may be features? It is a naïve question, but I'm genuinely curious.

There are some comments in existing files, but mostly this kind of information shows up in PRs. If you go look at whatever PR created most features with a compute_from or any feature with discouraged but no alternatives, then you're likely to find some discussion about how something might be a separate feature but it's inconvenient or confusing to mint one. But there's never been a conventional comment or structural cue for this.

I think there's a possibility to follow this up with annotations on BCD keys (e.g., to flag keys as candidates for break up and the like). I think it would be a nice thing to have.

Got it. I agree. I think making this information part of the data structure makes it more obvious!